Сервер.ПротоколОбмена
Сервер расположен по адресу http://85.21.240.42:8080/server/rest ВЕСЬ ОБМЕН XML ПРОИСХОДИТ В КОДИРОВКЕ UTF-8 Формат дат http://www.w3.org/TR/xmlschema-2/#dateTime Использовать формат без временной зоны, т.е. UTC Пример: 2011-09-01T11:40:45.629Z Если миллисекунды равны нулю, то сервер может их не присылать: 2011-09-01T11:40:45Z Регистрация Путь: /register Тип запроса: POST XML: Если регистрация завершена успешно, то возвращается обЪект user с дополнительными заполненными полями, такими, как id, version, subscriptionType. Авторизация не требуется. Обновление данных Путь: /update/{version} Тип запроса: GET XML: В поле {version} следует указывать версию, пришедшую в updateVersion с предыдущем апдейтом. Для первого апдейта в качестве версии нужно указывать 0: /update/0 Для доступа необходимо авторизоваться с логином и паролем, указанным при регистрации Заливка данных Путь: /commit Тип запроса: POST XML запроса: XML ответа: При коммите пользователь должен отправить все измененные данные с заполненым полем clientId. В ответе он получает информацию о каждом отправленном обЪекте - присвоенный сервером ID и версия обЪекта. Эти поля должны быть сохранены в базе. Связать отправленные и полученные данные можно по clientId. ЗАМЕТКА: clientId должен быть уникальным, т.е. если отправляются данные из разных таблиц, то имеет смысл перед отправкой добавлять к нему тип: Project id="17" уходит как clientId="project_17" Биндинг для передаваемых сущностей Ошибки Если выполнение команды завершилось ошибкой, то сервер пришлет информацию в следующем формате: " narrow /dev/hands Известные коды ошибок: UNEXPECTED("Unexpected server error: %s"), //что-то случилось на сервере TEST("Test error!"), TEST_WITH_ARGS("Test error: %s!"), INVALID_VERSION("Invalid version: %s"), INVALID_ID("Invalid id: %s"), PROJECT_SAVE_AUTHOR("Only author can modify project %s"), //код ошибки, возвращаемый при конфликтах коммита. //первый аргумент - это тип сущности - PROJECT, USER, TASK //второй - это серверный id сущности //эта ошибка появляется если: //в базе нет сущности с таким id и версией //в базе просто нет такой сущности SYNCH_UPDATE_REQUIRED("Update is required for %s, id=%s"), //возвращается при попытке обновления сущности, отмеченной как удаленная SYNCH_ALREADY_DELETED("%s is already deleted - update denied, id=%s"), //неизвестный код статуса проекта при приеме от клиента PROJECT_INVALID_STATUS_CODE("Unknown status code %s for project %s"), //возвращается при регистрации пользователя, когда одно из полей не заполнено (поле пересылается в том же формате, в котором фигурирует в User.java) REGISTER_MISSING_REQUIRED_FIELD("Field %s is required"), REGISTER_WRONG_LOGIN("Login can only contain alphanumberic characters, dot and underscope"), REGISTER_DUPLICATE_LOGIN("Login %s is already used"), //Возвращается при попытке послать на сервер объект со слишком длинной строкой в одном из полей FIELD_TOO_LONG("Field size can't be more than %s characters. Data: \"%s\""), //Возвращается, если неизвестный код статуса задачи или статус не указан TASK_INVALID_STATUS_CODE("Unknown status code %s for task %s"), //Возвращается, если неизвестный код типа запланированности задачи или тип не указан TASK_INVALID_PLANNEDTYPE_CODE("Unknown planned type code %s for task %s"), //При попытке отправить запрос на авторизацию от имени другого пользователя или множественный запрос USER_BAD_AUTH_REQUEST("User authorization request should contain only user's login: %s"), //при попытке добавить авторизованного пользователя без запроса авторизации. USER_UNAUTHORIZED_ADD("Unable to add user %s without authorization request"), //При попытке изменить список запросов на авторизацию как-либо помимо удаления запроса. USER_BAD_AUTH_MODIFY("Unable to modify auth requests - only deletion allowed, user: %s"), USER_SYNC_CREATE_NOT_ALLOWED("Unable to create user %s during synchronization - use registration instead"), USER_COMMIT_ANOTHER_USER("Commiting another user is not allowed"), //Попытка назначить поручение человеку, не являющимся авторизованным в контакт листе TASK_WORKER_AUTHORIZED_ONLY("Unable to assign a task to unauthorized user %s"), //попытка синхронизации задачи, к которой у пользователя нет доступа(не является автором или исполнителем) TASK_ACCESS_DENIED("User %s does not have access to task '%s'"), //попытка синхронизации элемента переписки с неверным кодом типа TASK_INVALID_POST_TYPE_CODE("Invalid task post type code: '%s'"), //попытка отправки измененного элемента переписки на синхронизацию TASK_POSTITEM_UPDATE_NOT_ALLOWED("post item update not allowed"), //отсутствие одного из полей при коммите задачи с аттачментом TASK_INVALID_ATTACHMENT("invalid attachment: %s"), USER_PASSWORD_TOO_SHORT("User password should be at least %s chars long"), //неверная попытка изменить статус поручения исполнителем TASK_INVALID_STATUS_CHANGE("Unable to set status %s of task %s"), FILE_IS_TOO_LARGE("Upload file size cannot exceed %s megabytes"); Заливка файлов Используется для заливки на сервер аватарок и прикрепленных файлов. Заливка файла Путь: /file/name/{fileName} , где fileName - имя файла, который заливается Тип запроса: POST Требуется авторизация. После успешной заливки будет возвращен XML следующего вида: По этому id можно в дальнейшем загрузить файл Загрузка файла Путь: /file/{id} Тип запроса: GET Требуется авторизация Коды статуса проекта /** Выполняется*/ WORK, /** Выполнено*/ DONE, /** Архив*/ ARCHIVE, /** Отменен*/ CANCELLED Коды статуса задачи //выполняется WORK, //в работе - исполнитель прочитал поручение и выполняет его WORK_IN_PROGRESS, //выполнено DONE, //архив ARCHIVE, //отменено CANCELLED, //корректировка CORRECTION Переписка в поручениях Коды типа элемента переписки /** Комментарий*/ COMMENT, /** Отчет*/ REPORT, /** Запрос корректировки*/ CORRECT Удаление В каждом обЪекте есть свойство deleted - если пользователь что-то удаляет, то клиент обязан выставить это свойство в true и закоммитить обЪект. Если после апдейта свойство deleted = true, значит обЪект был удален на другом устройстве и удаление было закоммичено. Типы запланированности задачи /** Запланировано - дата планирования содержит валидную дату*/ PLANNED, /** Запланировано на вкладку "Следующие" */ NEXT, /** Запланировано на вкладку "Когда-нибудь" */ SOMEDAY, /** Не запланировано*/ UNPLANNED Авторизация и добавление пользователей в контакт-лист Авторизация реализована примерно как в скайп - один из пользователей отправляет запрос на авторизацию, второй подтверждает и они автоматом добавляют друг друга в контакты. * user1 добавляет к себе в контакт нового пользователя с authorized=false * user1 коммитит, после чего у user2 в authRequests появится логин user1 * user2 апдейтится и либо добавляет к себе в контакт user1 authorized=true, либо удаляет из authRequests user1 * после коммита и апдейта оба юзера будут иметь в контактах друг друга ВНИМАНИЕ: Т.к. вашего юзера могут модифицировать извне (при авторизации), то при коммите будут конфликты - нужно аккуратно мерджить входящие изменения (список контактов и authRequests) c исходящими(список контактов, фио, пароль и т.п.) Для лучшего понимания привожу названия тестовых случаев: *При сохранении другого пользователя возвращается ошибка *При запросе на авторизацию к список контактов authorized=false второму юзеру отсылается логин в authRequests *При отзыве запроса на авторизацию у второго юзера убирается это имя из authRequest *При отказе в авторизации у первого юзера удаляется контакт *При подтверждении авторизации обоим юзерам добавляется контакт authorized=true *При удалении юзера из контакта этот юзер удаляется из контакта другого юзера *ВСТРЕЧНАЯ АВТОРИЗАЦИЯ. Если с при апдейте u2 пришел u1 ,а у u2 уже есть запрос на авторизацию u1 , то не коммитим на сервер этот запрос. *Нельзя добавлять в список контактов authorized=true, если нет запроса на авторизацию от этого юзера *При сохранении юзера запросы авторизации могут только удаляться, а не добавляться или меняться Поиск пользователей Путь: /searchUsers Тип запроса: POST XML запроса: Ответ: со списком пользователей, удовлетворяющих запросу Логин и почта ищется по полному совпадению, имя и фамилия - по подстроке без учета кейса.